如果把「幫我做一個網站」丟給 AI，幾分鐘後也許就有一個看起來能用的畫面。但畫面出現，不等於需求清楚、資料正確、測試通過，更不等於能安心交給使用者。這正是我想做這個 30 天系列的原因：把 ChatGPT 與 Codex 放進同一個真實開發流程，看看它們究竟能幫忙到哪一步。

我不打算用「AI 取代工程師了嗎」這種大問題當結論。接下來 30 天，我會把每個問題拆成能操作、能檢查的小任務，保留原始指令、修改內容、測試結果與我介入的地方。成功要有證據，失敗也要留下來。

這 30 天要做出什麼？

系列將以一個小型「任務追蹤 Web App」為實驗主線。預定的最小版本讓使用者新增、編輯、完成與篩選任務；後續再逐步加入 API、資料儲存、輸入驗證、錯誤處理、測試、部署與 CI。之所以選這個題目，是因為功能容易理解，卻會碰到前端、後端、資料與上線後維護等完整工程問題。詳細需求與技術選型會在 Day 4、Day 5 定稿；若當時發現範圍不合理，我會記錄調整理由。

Day 30 的交付目標不是一張漂亮截圖，而是一個別人可以打開的展示版本、一份能照著啟動的 README，以及能重現主要行為的測試。同時，我會留下每次 AI 協作的任務描述、程式碼差異、驗證紀錄和修正過程。專案能不能達到這個目標，要由後續實作與驗收決定，不能在第一天先宣告成功。

ChatGPT、Codex 和我各做什麼？

我的初始分工是：用 ChatGPT 討論需求、比較方案、找出模糊處；讓 Codex 在 Repository 中讀程式、改檔案、執行可用的檢查；我負責決定範圍、確認取捨、審查差異與接受結果。這只是待驗證的工作假設，不是產品能力排行榜。若某個任務交給另一方更有效，我會在系列中修正分工。

關鍵是把「AI 說它做完了」和「我確認它做完了」分開。任何功能都要回到需求和驗收條件；任何修改都要看 diff；能測試的地方就跑測試。遇到外部服務、權限或部署等動作時，也要先確認影響範圍。AI 可以加快嘗試的速度，但是否採用一個結果，仍由我負責。

我會怎麼判斷這場實驗？

每個任務至少記錄五件事：① 任務目標與驗收條件；② 實際送出的 Prompt 或任務描述；③ AI 改了哪些檔案、花了幾輪；④ 測試、手動操作與 Code Review 的結果；⑤ 我介入修正了什麼。這些資料會幫助我區分「第一次就做對」、「提示後才做對」和「最後仍需人工完成」。

有些指標可以數：完成時間、修改次數、測試通過率、額外改動的檔案數、人工修正次數。有些只能靠具體例子說明，例如需求理解是否到位、程式是否容易維護、錯誤處理是否合理。我不會把一個測試綠燈當成品質的全部，也不會用一兩次成功推論所有專案都適用。

今天的第一份任務描述

為了讓後續文章可以比較，我先寫下這個系列會反覆使用的任務格式。Day 1 只建立框架，還沒有把它當作已完成的 Coding 實驗：

目標：說清楚這次要解決的使用者問題。

範圍：列出可以修改的功能與不在本次處理的事項。

驗收：寫出可以操作或執行的成功條件。

證據：保留原始 Prompt、diff、測試結果與人工修正。

之後我會用同一套欄位交付任務，再比較模糊指令與明確指令造成的差異。若 AI 提出看似合理但無法驗證的說法，我會先把它當成待查假設，而不是文章結論。

Day 1 的結果與限制

今天完成的是實驗邊界：暫定主線專案、30 天交付目標、三方的初始分工，以及每篇文章要留下的證據。今天沒有程式碼 diff，也沒有測試數字；把「尚未執行」寫清楚，正是這個系列的第一條紀錄規則。真正的能力比較，要等同一類任務在可比條件下執行後才能開始。

今天學到什麼？

在寫第一行程式之前，先定義「做完」比先挑一個厲害的 Prompt 更重要。未來 30 天，我想回答的不是 AI 能不能產生程式碼，而是它的產出能否被理解、驗證、維護與交付。明天先從最基本的問題開始：ChatGPT 與 Codex 在這條流程中，到底各適合做什麼？